ThreadPoolExecutor#kill will wait_for_termination in JRuby; ensure TimerSet timer thread shuts down cleanly
#1044
+6
−2
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This fixes an inconsistency in behavior in ThreadPoolExecutor in Ruby and JRuby.
Extracted from #1042, explained in #1041.
Changing the behavior of
killto wait until all threads exited exposed a problem withTimerSet's timer thread. It was not previously being completely shut down. The change was to ensure that the loopedEvent.waitis released withEvent#seton shutdown.One wrinkle in TimerSet is that shutdown is wrapped with a mutex that also is locked in the timer thread, which could lead to a deadlock: shutdown takes mutex and waits for timer thread to exit; meanwhile the timer thread is itself trying to acquire the mutex in order to execute through and exit... therefore deadlock. My solution to this was moving the timer thread's kill / await-thread-termination outside of the mutex.
This deadlock was largely masked because JRuby wasn't waiting on the threads to exit (changed in this PR) whereas CRuby would simply kill the threads so they would have a chance to deadlock on the mutex.